The following known issues occur when upgrading from Groovy 1.6.3 (N4 versions 2.3 and earlier) to 1.8.6 (N4 versions 2.4 and later):
With Groovy 1.8, the 'static' and 'final' member variables cannot be included in the same line of code. This appears to be a Groovy bug. As a workaround, you need to change the variable to either 'static' or 'final'. You cannot include both.
Customers can no longer access private member variables due to a 1.8 language feature.
At times, there are issues with compiling scripts that use Anonymous Inner Classes. Therefore, avoid using these. If Anonymous Inner Classes are used, a "NoVerify" compilation error might occur when N4 starts up and the Groovy file will not run.
After upgrading Groovy libraries, you need to retest all your Groovy code extensions. This includes but is not limited to reviewing:
The start-up process
Code extensions and Groovy plug-ins
Web services
Public methods
The start-up process
During the start-up process, N4 tries to compile some of the pre-deployed Groovy scripts and writes messages to the log files when it cannot compile them. You must address any issues reported in the logs. For system-delivered Groovy scripts, please inform N4 Support.
Code extensions and Groovy plug-ins
N4 versions 2.2 and later have compilation actions added into the N4 system. This uncovers any compilation issues in the shared code that is placed in the Groovy Plug-ins view (on page 1) or in the Code Extensions view (on page 1).
This does not cover Groovy code placed in-line in EDI, Notices, or Road features.
Web services
If your Groovy scripts call external web services, ensure that you conduct tests that exercise them. This uncovers any runtime issues that are not compilation issues or that are embedded in a product feature that does not use N4 plug-ins.
Public methods
N4 has a small set of published Groovy APIs and a large number of public methods that are usually exposed for inter-module interactions. In some cases, your Groovy scripts may be using an N4 API that is not expected to be used externally. Therefore, if a N4 public method is refactored in a minor or major release of N4, you must catch it before you roll out N4 into production.
To test Groovy code extensions after upgrading to a new release:
Do one or all of the following:
In the N4 Code Extensions view (on page 1), select all code extensions, and then Actions 
Compile Code Extensions, or right-click and select Compile Code Extensions.
Run the following Groovy code from the Script Runner window (Administration DBA Script Runner).
import com.navis.argo.ArgoAssetsEntity
import com.navis.argo.ArgoAssetsField
import com.navis.argo.business.api.GroovyApi
import com.navis.argo.business.atoms.DigitalAssetTypeEnum
import com.navis.argo.business.event.groovy.GroovyClassCache
import com.navis.framework.business.Roastery
import com.navis.framework.portal.QueryUtils
import com.navis.framework.portal.query.DomainQuery
import com.navis.framework.portal.query.PredicateFactory
import com.navis.argo.business.reports.DigitalAsset
/**
* Author : Navis
* Simple Groovy to go over all the groovy codes in the digital assets table and report error if it can't be compiled on the deployed system where it is run.
* The code can be enhanced to cover more aspects, this is just a sample. Tested this with 1.0 version groovy,
* to keep it portable. Should you change this, please don't use 1.6 version API's like advanced loop syntax etc here to keep it runnable in all versions of N4.
*/
public class GroovyCompilationTest extends GroovyApi {
public String execute() {
DomainQuery dq = QueryUtils.createDomainQuery(ArgoAssetsEntity.DIGITAL_ASSET);
dq.addDqPredicate(PredicateFactory.eq(ArgoAssetsField.DA_FORMAT, DigitalAssetTypeEnum.GROOVY));
List list = Roastery.getHibernateApi().findEntitiesByDomainQuery(dq);
Iterator iterator = list.iterator()
StringBuilder sb = new StringBuilder();
sb.append("Summary of Groovy Compilation\n");
String groovyId;
while (iterator.hasNext()) {
DigitalAsset da = (DigitalAsset) iterator.next();
String groovyCode = da.getDaGroovyCode();
groovyId = da.getDaId();
try {
Class groovyClass = new GroovyClassCache().parseGroovy(groovyCode)
String className = groovyClass.getSimpleName()
sb.append("SUCCESS : " + groovyId + "\n")
// in 2.4 following lines can give some hints for runtime violation of groovy 1.8 rules (used in 2.4)
if (groovyCode.contains("static final") || groovyCode.contains("final static")){
log(A known bug with Groovy 1.8 prohibits including the 'static' and 'final' modifiers in the same line: " + className);
}
} catch (Exception e) {
sb.append("FAILED : " + groovyId + "\n").append("Stack" + e.getMessage()).append("\n");
}
}
return sb.toString();
}
}
This script prints a summary of the failures and successes. For example:
Summary of Groovy Compilation
SUCCESS : NavisUnitUpdateGroovyPlugin
SUCCESS : NavisGateGroovyPlugin
SUCCESS : NavisPrintReservedContainersGroovyPlugin
SUCCESS : NavisUnitRetireIDOEmail
SUCCESS : NavisUnitFixPodAndObCv
SUCCESS : NavisUnitDamageInsert
Stackkey=ERROR__NULL_MESSAGE parms=[Failed to parse groovy action:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, script1300321791303.groovy: 6: unable to resolve class com.navis.xpscache.ParticipantCacheManager
Set up an IDE project (in Eclipse, IDEA, or any other IDE) that contains all of your Groovy scripts and the latest N4 .jar files. Then try to compile the project in the IDE. If it fails, this indicates incompatibility between N4 .jar files and the existing Groovy scripts.
Write an Ant project that performs the same function as the IDE above. For this, you need to download Ant from the Apache Web site and create an Ant project containing your Groovy scripts and the latest N4 .jar files. If the Ant project fails to compile the Groovy scripts, this indicates incompatibility. In this case, you should resolve any issues before you roll out the new N4 version into production.
These recommendations address only compilation issues with Groovy that uses plug-ins or extension points as defined in the Extension Type Registry view. Also, they do not detect any runtime changes in the behavior of the APIs. To verify runtime behavior changes (semantics), you need to do actual use case testing in a deployed testing environment.